DEV9: Always bind UDP ports in sockets #12042
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Changes
Always bind the UDP source port when using sockets
Reworded some logs
Duplicate FixedPort's connections vector for resetting child connections
Rationale behind Changes
Previously, we would only bind the UDP source port in specific situations (Broadcast, multicast and when src and dst port similar).
This proved inadequate for some games, which would either fail to connect of behave strangely if the source port wasn't maintained.
Expanding the heuristics used to catch every game seemed non-trivial, so I've opted to forgo this previously used heuristic and always bind the port.
This does mean we now sometimes bind the port unnecessarily (namely DNS requests), however, different games use ranges for dynamic ports, so avoiding this seemed not worth the effort.
Additionally, FixedPort's
Reset()
method could potentially iterate over a modified vector if the child connection closed itself (and thus got removed from the connections vector in FixedPort's connection closed handler).Duplicating this vector avoids that situation.
This also allows us to reduce the scope of the lock in
Reset()
, avoiding a deadlock (or crash) as FixedPort's connection closed handler would also try to lock.Suggested Testing Steps
Test networking using Sockets